Context

Switch mode performance is very bad now (1 sec per change tag) which leads to poor UX. This PR makes it instant.

I looked but can not find any reason to keep it depending on full state update since the data is already loaded for presentation. I may be missing a reason for this architectural choice so please check.

There is also an issue I noticed Settings has a Save button but "Prompts" does not, can we standardize this? I prefer save button for clarity, autosave is OK too but would need user feedback. Either way we should standardize saving behavior across all tabs.

The other thing is, are we sending full convo history because we intend to actually change the mode in conversation or is that a bug? I neither believe users have this expectation nor do they really want that to happen. It's much better for users to have good UX on the modes page than trade-off bad UX for mode change for feature which user probably do not want. But I'm making a lot of assumptions here and maybe switching Mode here was never intended to influence the chat conversation... In that case we could turn off all backend updates until the user presses the save button which would be optimal from a cursory glance.

Screenshot

Details

For this PR:

The issue occurs because the UI waits for a complete round-trip:

1. Frontend sends mode change to backend
2. Backend processes it and updates global state
3. Backend sends back a complete state object (including conversation history)
4. Frontend deserializes this large state object and only then updates the UI

Solution

Implemented an "optimistic UI update" pattern that makes mode switching feel instant:

1. Added a local visualMode state that's initialized with the global mode state
2. Updated all UI components to use visualMode instead of mode
3. Updated visualMode immediately when a mode is clicked
4. Still sent the mode change to the backend for persistence

This approach provides instant feedback to the user while maintaining proper state synchronization with the backend. The key insight is that we don't need to wait for the backend to update the UI - we can update it immediately and let the backend catch up in the background.

Implementation Details

The changes are minimal and focused on the frontend only:

• Added a visualMode state in PromptsView.tsx
• Updated all UI components to reference visualMode instead of mode
• Modified the handleModeSwitch function to update visualMode immediately

Testing

• Manually tested mode switching between all available modes
• Verified that the UI updates instantly when clicking on mode tabs
• Tested rapid mode switching to ensure no flickering occurs

Impact

This change significantly improves the user experience when switching modes in the PromptsView component. What previously took 1-2 seconds now happens instantly, making the interface go from annoying to usable.

The changes are isolated to the frontend and don't modify any backend code, making this a lower-risk improvement.